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DirCrypt is a particularly nasty variant of ransomware. In addition to encrypting most 
of the user's files and demanding ransom for their decryption, the malware stays 
resident in the system, and immediately encrypts any new file which is created or 
saved. Therefore, the user is completely prevented from using the computer normally. 

The normal advice to victims of ransomware is to recover files from some previous 
backup. If there isn't a backup, the victims are given the option of either accepting the 
loss of their data— or paying the attacker. However, Check Point's Malware Research 
Team has found that in the case of DirCrypt, victims of the malware can recover almost 
all of their data, due to several weaknesses in the way the malware implements its 
crypto functionality. 

FINDING THE VULNERABILITY: TECHNICAL ANALYSIS 

A typical victim of DirCrypt will know about the attack only after the damage had been 
done. The malware sweeps through the file system, targeting documents, images and 
archive files. The suffix of the affected files is changed to '.enc.rtf '. Upon clicking one 
of these files, the user will not find any trace of their previous content; instead, an RTF 
document is displayed with instructions on how to pay the ransom. 
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Figure 1 : File system before encryption 
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Figure 2: File system after encryption 
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[EN] The file is encrypted 

To decrypt the file, follow these steps: 

1 . Disable antivirus (and firewall) installed on your computer 

2. Enable internet connection 

3. Unpack the archive C:\Documents and SettingsWdministrator\Local 5ettings\Application DataUgMzfKfq\Uxumyizgzip 

4. Run the unzipped yPeppml_X.exe 

5. Enter the correct code voucher Ukash, Paysafecard orMoneyPack 

6. Do not restart the computer. Expect complete decoding 



Figure 3: The ransom letter 
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This is where we begin our hunt for the malware's soft belly. The disassembled code 
itself is complex and obfuscated, so we need a shortcut to the main encryption 
function. Since the '.enc.rtf suffix is appended to the name of every affected file, we 
can make an educated guess that a reference to this string will be made somewhere in 
the proximity of the encryption function. However, a quick look in Hex-Rays' IDA-Pro 
will reveal that most strings in the binary have been obfuscated. So here's challenge 
number one: decrypt the strings in the binary. 

One approach to finding encrypted data in the binary is to simply scan through the 
sections and look for a blob of seemingly random data with no apparent meaning. 
Then, we would look for a function which has a data xref to this binary blob, and would 
look to see whether this function is called from many different parts of the code. If this 
function is further passed an index which appears to be within a certain limited range, 
then that is a dead giveaway: We have the string decryption function. 

Finding the encrypted blob was fairly easy, since it's quite straightforward to locate a 
large chunk of high-entropy data in the .data section. 

















; char EncryptedStringsBlock[ ] 


D9 


H6 


Bh 


no 


23 


FA 


BA* 


EbCIM|pted5|trlligsBlock db GD9h, 086b, 0B4H, OAOh, 23h, OFdh, OBAh, OFGb, 0F1h 


FO 


F1 


38 


9F 


05 


6E 


09* 


; DATA XREF: sub_4098CF*Dlo 


5F 


79 


D8 


BR 


*8 


FC 




; DecryptString*1Bto ... 


88 


83 


C5 


83 


A3 


A3 


2Et* 


db 3fill, 9Fh, 5, 6Eb, 9, 5Fh , 79h, 0D8h, BBBh, HBh , OFCh 


OC 


15 


51 


60 


hi) 


17 


ai> 


db ODMh, 8Ab, 0B3h, 0C5h , 3 dup(6A3h), 2Bh, OCh , 15h, 51b 


75 


95 


4F 


CM 


E6 


C8 


6A» 


db 68b, OFDb, 1711, BCb, 75h, 95b, 4Eh , 8CMI , GE6h , OCSh 


38 


't9 


60 


6D 


6D 


50 


BE » 


db fifib, 38h, l*9h, 60h, 2 dup(6Db), 5Dh, BBEh , BACIl , 56h 


AC 


56 


nn 


2? 


9F 


96 


D9» 


db mm, 22h, 9Fh, 96b, BD9h, 9311, 2Db, 89h , 51b, 82h 


93 


ZD 


E9 


51 


82 


32 


F8» 


db 32b, OFBb, 99h, 79b, 0B8b, QF8h , 99h, 79b, OB8I1 , BF8h 


99 


79 


BB 


F8 


99 


79 


BS* 


db 99b, 79b, OBBb, OFBb , 99b, 79)1, OBSh, 0F8b, 99il , GB3h 


F8 


99 


79 


BB 


F8 


99 


79* 


db 0F1h, 5Eh, 83h, 18h, OCFh, ODQh , 9Fh, 0D3b, ODE It, »B7h 



Figure 4: The encrypted strings 



Looking at the xrefs for this encrypted block, we see that this data is referenced by 
several functions, one of which is itself referenced 1 70 times throughout the code. Upon 
examining the way that this function is called throughout the code, we can observe that 
it is passed an index value as a parameter. Bingo, we got what we're looking for. 

The code for actually decrypting the strings is long and complicated. Since our target 
is to reach the actual file encryption code as quickly as possible, we will gracefully skip 
reversing the string decryption algorithm, and will instead whip out this simple Windbg 
snippet which does all the heavy lifting for us: 

.while (@$t0 < Oxel) { .printf "\n%02x", @$t0; r eip = 0x40456a; 
p; p; p; eb esp @$t0; p; du @eax ; r $t0 = @$t0 + 0x01 } 

This code repeatedly calls the decryption function with different index arguments, and 
outputs the decrypted strings to the terminal. A sample of the result is shown below: 



Q0ea362Q 
00ea3&5B 
0[lea363B 
Odea 3 6*8 
Cl [lead be 8 
00ea3703 
00ea3740 
Q0ea373Q 
0Cles37dQ 
03es3BDa 
00ea3B3B 
006*3373 
03ea33b3 
00ea3903 
Q3ea3950 
0[Jea3998 
0 3ea39d0 
03ea3al0 
03ea3a30 
03ea3a53 
00ea3a98 
Q0ea3ab3 
0 0ea3ai B 
03ea3b20 
03ea3b60 
03ea3ba0 
00ea3be0 
00ea3c20 
Q0ea3c&D 



-, SetPayInfo( " " 
"SetStatusC " 

' 

* )i* 

"Hicrosof t Enhanced Cryptographic' 
™ Provider vl . 0 " 

"Sof tware^Microsof tMJiiidows"vCurre" 

"iitVersioii^policies^systeift" 

" D isab 1 eTaskHgr " 

"EnableLUA" 

" =.'/ ETEH ■■•Curxeri t ContT-olSet VSerwice" 
" s\SliaxedAccess\Pcirci.me t exsNFi rewe " 
" 1 lPolicy^StandardProf i le " 
"DisableWotif ications" 
" DoHo t A 1 lowEscep t ions " 
"EnableFirewall " 

" LYITEM" Cu.rzen.tCcait2"-olSet\Service" 
" Start " 

"SOFTWAEEXMicxcisof t"V5ecuri ty Cent " 
"Br" 

"SOFTWAEE^Microsof insecurity Cent " 
" erSSvc " 

"SySTEH s -CiirTentContz , alSet\Contr'Dl " 
" \Saf eEc»- t '■•Net-work" 

" SYSTEM\C-urren t Control Set \Cont xol " 

" "\Sa £ eBoo t\M in iina I " 

■ SYSTEM^Curr en t Contro 1 Set vCont rol " 

"■-■bateEoot" 



Figure 5: Sample output of the Windbg snippet to decipher 
the crypted strings 
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Now we just need to transfer these results into IDA-Pro for static analysis. We chose to 
enter the decrypted strings as comments in places where they are used. An IdaPython 
script included below takes a file ("strings.txt") which contains a dump of the Windbg 
results and adds them as comments where they are being decrypted in the code. 

Another convenient option is to create an ENUM with the hex values and put the actual 
string as a repeating comment on the enum value. 

The result allows us to jump directly to the string reference that interests us by opening 
the xrefs to DecryptString dialog. 



ISi xrefs to DecryptString 


Direction 


Typ 


Address 


Text 






tH Up 


p 


na_ConnectToC2+33 


call 


DecryptString 


"http://46.165.192.94r 


iM Up 


p 


na_ConnectToC2+8D 


call 


DecryptString 


0x67 OxSa Oxce 0x52 


Up 


p 


na JnitCriticalSection +46 


call 


DecryptString 


"SoftwareV 


Up 


p 


sub_401DA7+54 


call 


DecryptString 


"\u%.4u?" 


«i up 


p 


na _Ch e ckFile And Add ToEn c . . . 


call 


DecryptString 


T 


M up 


p 


na _File5e a r ch Func tion_+ 33 


call 


DecryptString 


T 


lis up 


p 


na _Enc ry ptFi 1 e And C h ange . . . 


call 


DecryptString 


".enc.rtf" 


<*1 Up 


p 


na _Cr e ateArialFon t+23 


call 


DecryptString 


"Arial" 


M up 


p 


sub_402DOF+23 


call 


DecryptString 


"STATIC" 



Figure 6: Identifying where the scripts are being decrypted 



A quick look at the xref table would reveal that a string '.enc.rtf is referenced in one place in 
the binary. Since this is the suffix appended to the encrypted files, we are safe in assuming 
that we have homed in on the place where the actual file encryption takes place. 

The function which references '.enc.rtf has a pretty basic code flow: Much of the work is 
done for us, since IDA-Pro correctly identifies the function argument as a filename. At the 
beginning of this function, another function is called, then the string is deobfuscated and 
appended to the existing filename. The existing file is then renamed to include the new 
suffix. From this flow, we can infer that the original file is encrypted before being renamed 
with a new suffix. Only a single function is called before this renaming takes place, so it 
seems like we have a likely candidate for the file encryption function. 
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tryptFile(ln<ICharigeSufFi>.(LPCIISTR IpExistingFlleltaiH.) 



NULL P 
HULL. HULL 

shnrl Ion 1.82139 



diSansoroLetterSLze ; duRansoiiLetterSize 
pan : pszRansonLetter 

■Hanp] ; psrFilpnanplDFncryp 



HOC push 
BIB push 

■ push [•■lip 

B call FilpEncrjiptionFunctinn 



■ - IS 



BBC f.ii-.n NULL 

BIB push HULL 

— U push HULL 

: now [ebp*lpHeufileN 

J call OecnjptString 



a push tax ; pszstrTonppena 

'( push [ebp-lpLxiot ingf-1 loHano J ; pszExi stings tiding 

618 led tax, [ebp'lpNpuf ileHsne] 

B push tax : ppszHpvString 

aic push null | Lat 

call ConcatStringUrapper 



028 add psp. 2B 

GBC push fifth ; dulndrx 

aie call EncryptString 

enp Iebp*lph*irfileNansJ, HULL 

UUC jz short loc_t>2«? 



[pbp<lpNeurileHane] : lpNeufileHane 
[cbp-MpExistingFilpNanp] ; lpExistingFilph 
■sehmmfIim 

[■>bp*lpHeuFileHane] ; lpNen 
•si, tax 
Fl H Hi 



loc_WH39: 



Taking a peep inside what we suspect to 
be the encryption function, we can see a 
long code flow with a repeating pattern: 
Data is read from a file in chunks, modified, 
and written back. This is classic behavior 
for a crypting function, and we can now 
safely conclude that this is indeed the file 
encryption function. 

We have found our target. Now let the 
fun begin. 

From a quick glance, we'll find out that the 
malware repeatedly reads chunks from the 
target file, encrypts the contents of these 
chunks in memory, and then writes the result 
back to the same offsets, thus overwriting 
the plaintext data. 



Figure 7: The outer wrapper to the real encryption function 



lpFileChunkToBeRSAEncrypI > = (char )RllocateHeap(0, loc_dwRansDiiiLetterS:i ); 
if ( TlpFileChunkToBeRSftEncrjipted ) 

goto PrppareForExit ; 
pszRCMox = GenerateRC4SBox(TenByteSy«imetriclfey , 18); 
if ( pszRC'iRox ) 
< 

while ( dwDistanceToMoue < 512000 ) 
< 

duSizeflFReadBuf f er - Readfile(hFilp, lpFileChunkToBeRSHEncrijpted , 1B24u); 
if ( 'dwSizeOfReadBuFFer ) 
break; 

err = HdjustFilePointpr(riFile, duDistanceTrjHoue , B, 0) ; 
if ( (u12 £ err) == -1 

|| !RCiEncri)pt(lpFileChunkTDB?RSAEncri)ptpd, dwSizeOf ReadBuf fer , p5zRC4Box) 
j !WriteToFile(hFile, lpFileChunkToBeRSAEncrypted , dwSizeOf ReadBuf Fer) ) 

break ; 

duDistanceToltaue += duSizeOf ReadBuf fer ; 

> 

FreeHeapUrappertpszRCiiBox) ; 



Figure 8: The encryption loop 



Going into some more depth, we can see that there are actually two separate encryption 
functions here. The first one is called on each chunk of the file, so that the whole file is 
encrypted. We can see that the function is passed a pointer as its first argument, and 
that the contents of this pointer are initialized in a separate function. To an experienced 
analyst, this function is instantly recognizable as the initialization of an RC4 S-box. 

The file encryption function is called repeatedly for each file, so the S-box is re-initialized 
from the same key for every file. The file is then encrypted using the RC4 keystream. 
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; duKeyLength 
: TenByteSijunetficKey ; pTpnByteSjjmraptricKey 
ItpRClSBoj 



short loc_<iB1FflEl 



loc_liB1FflE: 
B7<i Clip [ebp*dwDistanceToMoue] , 5120BB 

B7U jh short loc_UB1F63 



loc_HB1Ffi3: 
B74 push edi 

878 push [ebp+lpFileChunkToBeRSfiEncrypted] 
87 E push hFile ; hFile 



; nNumbei'Of BytesToRpad 

lpBuFfer 



If you've seen some crypto bloopers in 
your life, this should definitely make you 
do a double take. Because the RC4 S-box 
is initialized from scratch every time, we 
are actually guaranteed to get the same 
keystream for each file. Let's take the final 
step. If we happen to know the plaintext 
contents of any file which is guaranteed to 
be on the victim's computer, all we need 
to do is xor to get the keystream: byte of 
plaintext A byte of ciphertext == byte of 
keystream. 



B7U push NULL ; dulloueMethod 

B7S push NULL ; dMDist^nceToMoueHlgh 

B7C push [ebp*dwDistancpToHoup] ; lDistanceToHoue 

B8B push hFile ; hFile 

B8ii call fldjustFilePointer 



short loc 4B1FB7 



[ebp+p-^RCiRnxjii^dwSi^pnfRpatlRiiff pi-] ; pszRCiState 
[ebpi dwSizeOFReadBuf For ] ; dwSizeO main text 
[ebp+lpFilpChunkToBpRSAEnci-yptpd] ; pszPlaintpxt 
RCiEncrypt 



Figure 9: RC4 initialization and usage 



The only problem is finding a file which is guaranteed to be on the file system. Windows' 
sample images come to mind. Their average size is about 1 00k, so we get a keystream 
of this size without too much effort. 

Just as we were considering this problem, the following code caught our eye: 



■ rid 


074 

978 
970 


push 
push 
push 


[ebp+diiSizeOf Basic Filename 1 ] ; nNuinberOF Byt9£ToUrite 
[E-Bp+ps2BasicFilenaFM?] ; lpuuFfer 
hFile ; hFile 


USUI 


call 


HriteToFile ; Write Filename 


874 


test 


eax, eax 


97'l 


V- 


lnc_ii B2111 



■ ■ 




push 


Orth 




«78 


pop 


eax 






push 


eax 


; iHunberQf BytesTo Write 


878 


push 


□f Fset TenByteSumnietricltejj ; IpBuf f er 


S7C 


push 


ririlo 


; HFile 


08 0 


mou 


[9hin+dL'fL9nqtri0 FKey ] , eax 


08 0 


call 


Wl*it9T0FilC 


; Write key 


f\7h 


test 


eax, pax 




D7H 


V 


loc_MB2111 





Figure 1 0: Appending the RC4 key to the encrypted file (!) 

After picking our jaws from the floor, we started feeling bad for the poor malware author. 
Apparently confused about where to save the key, he somehow came to a decision that 
appending the symmetric key to the end of the file, where anybody can take it, is a pretty 
good idea. 

We also think it's a pretty good idea: We can now trivially decrypt everything encrypted in 
the file using RC4. 

But wait a minute: now we approach a different problem. The malware does not use just 
RC4 to encrypt the files. 
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■ at a 


1ocJi01FE2: ; 


nHumbei'DiFButesToRead 


074 push 






B78 push 


[pbp+lpFileChunkT 


oBeRSfiEncrypted] ; lpBuffei- 


07 C push 


hFile ; 


hFile 


B8II call 


ReadFile 




B7 H cnp 


pax, NULL 




074 nou 


[ebp+duSizeOf Read 


Buffer], eax 


074 jz 


loc 402111 





LJ ■■ 


a 




0/4 


cnp 




074 




[ebp+pszRC4Box cr dwSizeOf ReadBuf f tr] , eax 




J" 


short Iqc 4020B1 


L I 



" v — = 

a w b 

074 nou [ehp*psgRCiBoK_oh _di'iSizpOFReadBuffei-] , edi| 



a r* ■ 






loc 402 


801 : 




B7* lea 


eax , [ebp+pszCipherText] 




B74 push 


eax ; pszCipherTeHt 




078 lea 


eaic, [ebp+pdwDataLen] 




073 push 


eax ; in out pduDataLen 




07C push 


[ebp+pszRdBox or duSizeOFReadBuF f e-r] ; dwSizeOf Src 


Buffer 


089 push 


[ebp+lpFileChunkTaBeRSAEnct-ypted] ; pszSrc 




08<i push 


hKey ; hl(eu 




0SB call 


»SHCryptFun|ction 




0?l| test 






074 jz 


loc 402111 





Figure 1 1 : Encrypting the 1 024 bytes with RSA 



A single, 1 024-byte chunk at the beginning of the file is encrypted by RSA. The private 
key is nowhere to be found in the file, so one of the only ways to get it is to pay the 
ransom and get the key from the C&C server. Assuming that we do not want to pay the 
ransom (and don't want to attack the C&C directly), we're stuck with trying to rescue a 
file which had its first 1 024 bytes demolished. 

This is doable to varying degrees, depending on the format of the file that we want to 
rescue. Let's take Word (the original .doc format) for example. 



The Period 



it was th* near of times, 
it was Eh* wocj: of times, 
it was che age of wisdom, 
it was the age of foolishness, 
it was the epoch of belief, 
it was the epoch of incredulity, 
it was the season of Light, 
ic was the season of Darkness, 
ic was the spiring of hope, 
ie was the winter of despair, 
! had * very thing before ua, 
naa nocning Before us, 
were an going direct co Heaven, 
were all going direct the other way — 
short, the period was so far like the present period, that some of 

est -authorities insisted on its being received, for good or for 
evil, in the superlative degree of comparison only. 

There were a king with, a large jaw and a queen with a plain face, on the 
throne of England: there were a Icing with a large jaw and a queen with 
a fair face, on the throne of France. In both countries it was clearer 
than crystal to the lords of the State preserves of loaves and fishes, 
thai; -chings in general were seeded for ever. 



Figure 1 2: A word document which will serve as our guinea pig 



In a .doc file, the raw text (formatted in Unicode) starts at offset 0x1 A00. After letting 
DirCrypt encrypt our sample document, we can compare its contents before and after 
the encryption. 
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0 Q 


0 1 


02 


0 3 


04 


0 5 


0 6 


07 


0 3 


0 9 


OA 


0 p 


o c 




OF 


0 F" 


















00001A00 


M 


00 


6F 


00 


6F 


00 


6B 


00 


20 


00 


74 


C 0 


68 


0 '0 


65 


90 


B 


o 


o 


t: 




t 


b 


.e. 


00001A10 


20 


00 


46 


00 


69 


0 z 


72 


0 0 


73 


00 


74 


00 


2D 


0 0 


2D 


00 




¥ 


i 


r 


3 


t 






00001A20 


52 


00 


65 


00 


63 


00 


61 


0 0 


6C 


00 


6C 


00 


65 


00 


64 


00 


R 








1 


i 




ri 


0Q001A30 


20 


00 


74 


00 


6F 


00 


20 


0 0 


4C 


C 0 


6 5 


00 


6 6 


00 


65 


00 




t 






L 


i 


f 


.e. 


0Q001A40 


OD 


00 


OD 


00 


OD 


00 


OD 


00 


OD 


0 0 


49 


00 


2E 


0 0 


20 


00 












T 






00001A50 


54 


00 


eo 


00 


65 


DO 


20 


0 0 


50 


00 


65 


00 


72 


00 


69 


00 


T 


h 


e 




P 


e 


r 


. i . 


00001A60 


6F 


00 


64 


00 


OD 


00 


OD 


0 0 


OD 


00 


4 5 


0 D 


74 


00 


20 


00 


Q 


d 








I 


t 




00001A70 


77 


00 


61 


00 


73 


00 


2 0 


0 0 


74 


0 0 


68 


00 


65 


0 0 


20 


00 


w 








f 


h 






00001A80 


62 


00 


65 


00 


73 


00 


74 


0 0 


20 


00 


6F 


00 


66 


00 


20 


00 


b 


e 


£ 


t 




o 


f 




00001A90 


74 


00 


69 


00 


6D 


00 


65 


00 


73 


00 


2C 


00 


OD 


00 


69 


00 


t 


i 




e 


5 


r 




.i. 


0Q001AA0 


74 


00 


20 


00 


77 


00 


61 


00 


7 3 


00 


20 


00 


74 


00 


68 


00 


t 




w 


a 


S 




- 


li 


00001AB0 


€5 


00 


20 


00 


77 


00 


6F 


00 


72 


00 


73 


00 


74 


00 


20 


00 


e 




w 


: 


r 


5 


t 




00001AC0 


6F 


00 


66 


00 


20 


00 


74 


00 


69 


00 


6D 


00 


65 


00 


73 


00 


o 


f 




t 


i 


in 


0 


. s. 



Figure 1 3: The document in a hex editor (before encryption) 



Offset (h) 


00 


01 


02 


03 


04 


05 


06 


07 


08 


0 9 


OA 


OB 


OC 


OD 


OE 


OF 




OOOOIAOO 


[76 


2B 


C8 


D2 


F3 


54 


AO 


3 9 


89 


A3 


DB 


5E 


E8 


46 


OA 


95 


[y+EOoT 9h£f>eF. ■ 


OOOOIAIO 


35 


FO 


D7 


57 


D9 


00 


40 


01 


AC 


2E 


94 


3E 


6D 


71 


D3 


8 A 


53*WU.@.-..">mq6s 


00001A20 


10 


22 


Al 


Fl 


35 


D3 


42 


16 


C5 


aa 


02 


FO 


C3 


4E 


6D 


29 


."inSOB.A'.aANm) 


00001A30 


8 J 


9A 


0 6 


57 


16 


SE 


3F 


FB 


EB 


85 


3 0 


A8 


51 


62 


14 


B3 


„s.g.Z ue...0"Ob. ! 


00001A40 


FF 


ID 


1C 


34 


IF 


BO 


E9 


AE 


5C 


B4 


65 


Dl 


OE 


■ID 


5C 


El 


yM.4.°e<8\'e62K\a 


00001A50 


7C 


00 


08 


IS 


OA 


AA 


co 


98 


D4 


49 


40 


73 


EO 


7 4 


B3 


95 


I . . .5"A~OI@sat 3 ■ 


00001A60 


6F 


4 F 


V? 


4C 


CD 


1C 


D7 


75 


4 E 


Cl 


El 


B6 


C6 


66 


43 


BO 


oOdLra. xuNaa!JEfC° 


00001A70 


C9 


A7 


D9 


5E 


E5 


2F 


AB 


( E 


A2 


Dl 


49 


74 


C7 


33 


D7 


E2 


E§0 A a/«n4fiItg3xa 


00001A80 


49 


F8 


39 


SB 


C3 


94 


4A 


OE 


45 


15 0 


B5 


FO 


CA 


B6 


16 


51 


l09;A"J.E°uoEJ.Q 


00001A90 


CF 


BD 


08 


F7 


92 


37 


19 


OD 


A3 


Cl 


7F 


DC 


60 


68 


2A 


65 


.£A.0"h*e 


OOOOIAAO 


70 


AE 


5D 


FF 


D6 


4 0 


OE 


40 


4F, 


CO 


26 


01 


79 


F3 


61 


08 


p®] yO@ . @NAS.y6a. 
a-"FA. .a/.tep". . 


00001ABO 


E5 


97 


A6 


46 


C5 


7F 


05 


€1 


83 


1C 


87 


E3 


EE 


22 


08 


ID 


00001ACO 


36 


3B 


C9 


E3 


IE 


D6 


8B 


02 


7B 


IE 


70 


EC 


95 


70 


4 0 


BD 


6;Ee.O< . j .pl-pQH 



Figure 1 4: The document in a hex editor (after encryption) 



I. 


The 


Period 


It 


was 


the 


best of times. 


it 


was 


the 


worst of times. 


it 


was 


the 


age of wisdom. 


it 


was 


the 


age of foolishness. 


it 


was 


the 


epoch of belief , 


it 


was 


the 


epoch of incredulity. 


it 


was 


the 


season of Light, 


it 


was 


the 


season of Darkness, 


it 


was 


the 


spring of hope. 


it 


was 


the 


winter of despair, 


we 


had 


everything before us, 


we 


had 


nothing before us, 



We have written a simple Python script 
to fetch the RC4 key, decrypt the contents 
of the file (except for the first 1 024 bytes 
encrypted by RSA), fixing most of the 
Word header, and dump the text in ASCII. 

Running this script on a sample 
document, we can see that we have 
completely recovered the text of the 
document. A victory dance would be 
in order. 



Figure 15: The decrypted text in a text editor 



CONCLUSION 

In this whitepaper, we've shown some of the steps and approaches that you might 
take when trying to uncover a vulnerability in a cryptovirus. Our underlying purpose 
was to lead the way in showing that the kind of attacks implemented by this category 
of malware are reversible: sometimes less, sometimes more, but there is almost always 
a weakness that can be exploited to the benefit of the defender. 
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